星火在CRM商机智能分配场景的应用实践
导读
为了更好地支持销售人员获取商机，CRM系统提供了商销匹配、未覆盖分配、一键申领、新增商机分配、刷新商机分配等多种功能。AI侧使用个性化推荐算法、个性化搜索排序算法，通过直接提高成单链路中间环节的关键指标的方式，来提高最终的成单转化率。
CRM商机智能分配简介
CRM商机智能分配就是要在海量的历史商机中，给销售人员提供更优质的、更匹配的商机，从而提高成单转化率。相关商机分配详细逻辑请参见文章 《AI+CRM提高企业的绩与效》。
目前具体方式为：召回策略（海量商机中筛选数千商机）+排序策略（数千商机和销售人员组合打分排序）+重排规则（按规则重排，如提升覆盖率限制各召回源商机比例）。
黄页业务线营销模式分为两种：
（1）直销密歇根模式：销售团队分为商机组和销售组。首先，商机组人员需要拨打电话筛选出有意向购买会员的商机。然后，商机组人员将商机转出给销售组人员。最终，由销售组人员跟进至成单；
（2）电销模式：无密歇根模式，销售人员负责从拿到商机到成单整条链路的全部工作。
直销密歇根模式成单链路
电销模式成单链路
业务难点
算法实验需要多次进行快速的模型迭代，以探求最优的模型策略。
稳定迭代期有三种模型流量：
（1）主要模型：当前效果最好的模型策略，占线上流量的80%；
（2）基线模型：效果和主要流量相差不大的模型策略，占线上流量的10%，如果基线流量长期效果高于主要流量则被提升为主要流量；
（3）探索模型：新上线的模型策略，占线上流量的10%，如果探索流量短期效果高于基线流量则被提升为基线流量，如果探索流量连续3～5天效果不如基线流量，则进行下线处理。
面对算法模型的快速迭代、业务需求的快速增长，数据开发中存在以下几个问题：
（1）业务复杂且多变，开发难度高；
（2）数据需求高频迭代、数据应用需求快速增长，开发效率相对较低；
（3）数据口径不一致；
（4）烟囱式开发，数据准确性差，资源利用率低。
同时，为了对实验模型效果进行观察和流量变更，需要对每日的ABTest模型实验效果有直观的、及时的对比展示，灵活的、便捷的数据查询方式。
初期使用Hive云窗+云图制图+定时发送邮件功能，对每日ABTest效果数据进行对比展示，存在以下几个问题：
（1）业务复杂多变，维度组合展示需求同样复杂多变，而邮件的维度组合固定单一，导致报表量激增，邮件过长或者过多；
（2）查询效率低，云窗查询SQL语句，运行时长几分钟甚至十几分钟；
（3）效果展示不直观，无法自定义查询，无法下钻查看明细数据；
（4）灵活性差，开发效率低，维护成本高，难以支持算法模型快速迭代；
（5）可延展性差，无法支持后续实时效果展示等需求。
星火BI平台可以完美的解决以上的问题，并且支持ClickHouse、TiDB、Kylin、MySQL、Hive等数据源接入。所以星火上线后，模型效果迁移到了星火进行展示。
技术选型
星火是新一代具备SaaS能力的企业级数据分析可视化产品，提供智能BI、可视化报告、Dashboard服务、数据大屏等能力，以数据洞察为导向，从数据接入到终端展现，提供全链路数据解决方案。
星火BI平台支持的数据源对比如下：
需求：支持海量数据多维分析，支持实时数据接入，支持持续增加的维度和指标的快速扩充，支持下钻查看明细数据。
结合需求及难点，选择ClickHouse和Kylin进行对比。
相同点：
（1）二者都支持海量数据多维分析及下钻；
（2）二者都可以通过大数据平台快速配置Hive的定时导入；
不同点：
（1）Kylin多维分析底层，是对数据进行预聚合计算，存入HBase以快速查询，对有层级或互斥关系的维度有很好的优化方案，但增加维度需要更新Cube，重新计算；而ClickHouse是通过维度索引和列式存储，仅需读取计算所需列的数据，进行快速的聚合计算，增加维度不需另外重新计算；
（2）Kylin仅提供某种实时数据的支持；ClickHouse支持Kafka实时数据导入，对实时数据的支持性能更优良；
鉴于项目维度组合复杂且多变、维度之间相互独立、层级和互斥关系少并且后续需要展示与监控实时效果等特性，最终选择ClickHouse+星火的模式进行智能推荐效果的展示开发。
数仓重构
为了解决难点中提到的数据开发存在的问题，使用数仓维度建模的方式，对CRM商机智能分配使用的特征数据、正负样本打标数据、效果评估数据等进行重构。具体如何解决难点中对问题在文章问题解决中解答，这里对重构方式进行描述：
（1）数仓分层架构：分为ODS层、DWD层、MID层、APP层共4层。业界数仓分层架构大同小异，这里不再赘述。
（2）通过资料分析、系统访谈、信息验证、内容沉淀的方式进行系统调研，拆解出各个业务过程及维度，并抽象成集合，划分数据域。
a.维度的整合：统一表、字段的命名规范；统一相同、相似字段的类型；统一维度的公共代码值；整合业务含义相同、高概率同时访问的表，如整合订单表（58订单、赶集订单、安居客订单等），又如多个CRM的商机表不进行整合（业务有差别且不同时访问）。
b.维度的拆分：考虑扩展性、效能、易用性，根据业务关联程度及使用频率，将过宽的维度表按列拆分成主维度表和杂项维度表。主维度表支持常用的、核心的业务需求，杂项维度表支持临少量的、临时的个性化需求。如商机维度表，将某一产品线独有的、不常用的属性放到杂项维度表中，以商机id为主键维护两表关联性。
c.各实体间关系整合：统一各实体间对应关系，将对应关系冗余到实体的主维度表或者单独建设实体关系表，保证各实体关系准确性和唯一性。、
（4）事实表的设计：根据各数据域的业务过程，拆分出业务事实和度量，并冗余常用维度。其中事实表分为：事务事实表、周期快照事实表、累积快照事实表。根据业务需求设计不同的事实表，保证数仓使用方便性。下图对这三种事实表的异同进行说明：
事务事实表又分为单事务事实表和多事务事实表。查询商机被销售人员和系统更改的记录时，需要使用多事务事实表（CRM操作历史表）；查询商机被绑定的明细时，需要使用单事务事实表（从CRM操作历史中抽取的商机被绑定的行为，冗余绑定相关的事实维度，开发的CRM商机绑定明细表）。
为了满足不同的业务需求，事务事实表和快照事实表通常是成对设计的。商机智能分配效果展示使用频率最高的就是一张累积快照事实表，下文详细介绍该表的设计方式。
明细表设计
简介中已经说明，由于成单周期较长（90天），所以算法模型的目标，在于优化成单链路中间环节的关键指标，即推荐算法的CVR和CTCVR，具体如下：
（1）直销密歇根模式商机组：拨打转出率（接通且转出商机数/拨打商机数），接通转出率（接通且转出商机数/接通商机数）；
（2）电销模式、直销密歇根模式销售组：拨打60s有效率（通话时长大于60s商机数/拨打商机数），接通60s有效率（通话时长大于60s商机数/接通商机数）。
并且，关键指标仅考虑申领、分配后当天的效果，跨天的行为不纳入计算。
这样计算原因有四点：
（1）销售不跟进完成目前申领/分配的商机，无法继续进行申领，保证了销售当天可以跟进大部分申领/分配的商机；
（2）特征数据每日更新，隔天的效果与模型计算的效果不符；
（3）模型每日训练，特征分布变化不大及AUC有提升会更新模型，隔天效果与当天模型不符；
（4）每日计算前一日效果，即为最终效果，无需隔天再更新，能够及时对模型效果进行对比。
综上，数据可以抽象为一次申领或者一次分配的当天的生命周期（申领/分配-拨打-接通-时长超过60s-转出/释放）的数据，类似于订单生命周期（下单-支付-开通/到期/退款）。对于这种研究事件之间时间间隔、关注多个业务过程的累积作用的需求，可以使用维度建模中累积快照事实表的设计方式，极大的简化指标的聚合计算。
直销密歇根商机组漏斗 电销、直销密歇根销售组漏斗
结合累积快照事实表的设计方式，以及ClickHouse列式存储特性，明细数据设计方式如下：
（1）粒度：一个商机被分配/申领到一个销售人员的临时库中，即主键=商机id+销售人员id+SeqNo（一次申领/分配服务）；
（2）对多个事实进行关联，以1/0标记每一个业务过程是否发生，聚合时可以直接求和计算，同时也可以结合标记+id，去重计算某一个业务过程的商机数量，销售人数，调用的申领/分配次数等；
（3）冗余每一个业务过程的时间维度，未发生的业务过程时间，赋予默认值\'9999-12-31 00:00:00\'；
（4）冗余用于聚合和过滤的公共维度，如日期、产品线、城市、绑定类型、召回源、召回策略、排序策略、重排规则等；
（5）冗余特殊维度标记，如是否工作日、直销/电销、机器人/人工销售等；
（6）避免频繁更改ClickHouse元数据产生问题，预留20个字段供后续需求扩展，目前已使用12个预留字段，数据趋于稳定；
（7）严格限制所有字段类型，并对所有字段进行统一的null值处理，避免ClickHouse的数据类型转换问题、null值问题。
问题解决与功能实现
1.数据开发难点与解决方式
（1）业务复杂且多变，开发难度高。
公共处理逻辑下沉及单一：将复杂的、公用的处理逻辑在底层进行封装和实现，避免多处同时存在，能够保证数据的准确性，简化应用层计算逻辑，减少计算资源浪费，同时可以通过更改底层公共处理逻辑吸收业务变化。
（2）数据需求高频迭代、数据应用需求快速增长，开发效率相对较低。
高内聚和低耦合：将业务相近或相关的、高概率同时访问的数据放在一起，提升开发效率；
核心模型和扩展模型分离：核心模型支持常用的核心业务，扩展模型支持个性化、少量需求，保证核心模型的简洁性和可维护性；
命名清晰、规范、一致：统一表格和字段的命名规范，统一相同含义的字段命名及字段类型，减少开发成本。
（3）数据口径不一致，难以保证数据准确性。
公共处理逻辑下沉及单一：不再赘述；
统一公共代码值：保证公共代码值的唯一性，如产品线、各业务过程的事实维度等；
知识积累与沉淀：将关键业务知识、公共的计算口径落地文档，上传至iwiki进行同步。
（4）烟囱式开发，数据准确性差，资源利用率低。
统一划分数据域对数据进行管理，统一数据源及数据口径，并严格把控数仓分层的数据流向，在MID层开发公用的聚合数据供APP层计算使用；
合理利用分区表和parquet列式存储，减少资源浪费，提升任务执行效率。
2.BI展示难点与解决方式
结合星火+ClickHouse的方式，对应难点解决方式如下：
（1）业务复杂多变，维度组合展示需求同样复杂且多变。
在数仓底层吸收复杂多变的业务，对复杂业务判断进行打标，降低应用开发难度；
利用星火BI平台的维度对比功能绘制曲线图（底层实现为先按照横坐标维度+对比维度聚合计算指标，再以横坐标维度为主键，将对比维度结合对应的指标进行行转列操作，最后绘制曲线图），简化聚合及行转列sql开发；
利用星火BI平台筛选功能、下钻功能，对展示的数据进行筛选和进一步下钻展示，提升查询数据的敏捷性和效率。
（2）查询效率低，延迟时间几分钟甚至十几分钟。
对ClickHouse表常用的过滤及聚合字段建立索引，并充分利用ClickHouse列式存储特性，每次只查询所需列的数据，提升查询效率；
同时，使用星火数据缓存功能，短期内多次查询无需再次访问ClickHouse表，提高查询效率，降低ClickHouse的QPS。
（3）效果展示不直观，无法自定义查询，无法下钻查看明细数据。
使用星火的折线图功能绘制效果趋势图，并增加日期、城市、召回策略、排序策略等筛选项功能，可以直观对比效果，并通过筛选实现下钻对比、精确对比关注的某两条曲线等功能。
（4）灵活性差，开发效率低，维护成本高，难以支持算法模型快速迭代。
统一维护底层明细数据，并在星火共享数据源和数据集，供开发人员进行报表开发与数据分析工作。
利用星火维度对比、筛选项自动解析（解析该列所有枚举值去重）等功能，实现新上线模型曲线自动绘制、筛选项自动更新，降低维护成本。
（5）可延展性差，无法支持后续实时效果展示等需求。
ClickHouse支持Kafka数据实时接入，后续可以将实时日志处理后导入Kafka，通过平台将Kafka消息落地到ClickHouse表中，实现实时数据的接入和展示。
3.功能实现
CRM商机智能分配项目已经开发了20多张报表，支持不同产品线、不同营销模式、不同销售人员类型、不同绑定类型的ABTest效果对比，以及大盘趋势变化。这里介绍几个具体的典型功能实现及目标：
（1）关注每日召回策略、排序策略ABTest关键指标效果趋势对比图，对比主要流量、基线流量、探索流量效果，支持及时进行三种流量的切换。
线上各排序策略流量ABTest趋势图
（2）关注每日不同的召回策略+排序策略的组合趋势对比图，支持发现最优的召回策略+排序策略组合。
（3）关注每日不同维度组合的聚合数据，并提供下钻到城市的数据，支持及时关注各部分流量具体数据，进行数据分析和周报制作。
（4）关注不同维度组合多日聚合数据对比，比如周、月聚合数据，支持对浮动的数据更精准的评估，排除偶然性。
聚合数据和多日聚合数据统计表（日期城市等维度可筛选）
（5）关注关键指标大盘趋势，在流量切换前后，大盘整体趋势的上升及下降，并进行周、月环比，支持评估流量切换对大盘趋势的影响。
商销匹配全量切换纯推荐模式前后大盘趋势图
总结
在模型效果的考量上，通常需要从不同角度、不同维度组合、不同方式进行对比和分析。这就需要有更高效、更直观、更灵活的数据查询方式以及数据展示开发方式。星火BI平台+多种数据源支持，覆盖了模型实验的快速迭代对效果展示的99%以上的需求，并实现了秒级查询效率。未来持续进行数仓优化建设，在数仓底层数据支持下，新模式赋能、数据分析等新需求开发，可以在半小时内完成。
作者简介
58同城AI Lab简介